An enterprise depends critically on the information in its enterprise information system (EIS) for its business activities. Any loss or inaccuracy of information or any unauthorized access to EIS can be extremely costly to an enterprise. An EIS can be protected against such security threats using mechanisms that include identifying and authenticating principals; performing authorization and access control to determine whether a principal is allowed to access an application server and/or an EIS; and provide secure communication between an application server and EIS. Communication over insecure links can be protected using a protocol (for example, Kerberos) that provides authentication, integrity and confidentiality services. Communication can also be protected by using a secure links (for example, SSL).
A principal is an entity that can be authenticated by an authentication mechanism that is deployed in an enterprise. A principal is identified using a principal name and authenticated using authentication data. The content and format of the principal name and the authentication data depend upon the authentication mechanism.
A set of security attributes are typically associated with a principal. These security attributes are related to the authentication and authorization mechanisms. Examples include security role and permissions (for security principals) and credentials for a principal. A credential contains or references security information that can authenticate a principal to additional services. A principal acquires a credential upon authentication or from another principal that allows its credential to be used (principal delegation). An end user is an entity (human or service) that acts as a source of a request to an application. An end user is represented as a Subject as specified in the Java Authentication and Authorization Service (JAAS) framework.
An initiating principal is an end user who interacts directly with the application. An end user can authenticate using either a web client or an application client. A caller principal is a principal that is associated with an application component instance during a method invocation. A resource principal is a security principal under whose security context a connection to an EIS instance is established. A security domain is a scope within which certain common security mechanisms and policies are established. An enterprise can contain more than one security domain. Thus an application server and an EIS may be in same or different security domains. In a managed environment, application components are deployed in web or EJB containers. When a method gets invoked on a component, the principal associated with the component instance is termed as a caller principal.
An application component requests a connection to an EIS instance under the security context of a resource principal. The relationship between a resource principal and its attributes to a caller or initiating principal depend on how principal delegation has been configured in an operational environment.
The creation of a new physical connection requires a sign on to an EIS instance. A change of the security context on an existing physical connection can also require EIS sign on; the latter is termed as re-authentication. An EIS sign-on typically determines a resource principal under whose security context a physical connection to an EIS will be established. An EIS sign-on also authenticates a resource principal if it is not already authenticated, establishes a secure association between the application server and the EIS; and performs access control to EIS resources.
Various scenarios exist for EIS integration. These scenarios focus on security aspects of transactions. A J2EE application is a multi-tier, web-enabled application that accesses EISs. It consists of one or more application components—enterprise java beans (EJBs), java server pages (JSPs), servlets—which are deployed on containers. These containers can be web containers that host JSP, servlets, and static hypertext markup language (HTML) pages. Containers can also be EJB containers that host EJB components, as well as application client containers that host stand alone application clients. In the following scenarios, the description of the architecture and security environments are illustrative in scope.
FIG. 1A illustrates an application where a merchant maintains a portal on the world wide web (web) or other computer network where customers may access the portal and purchase products offered by the merchant. Such a portal is referred to herein as an eStore. Company A has an eStore application based on the J2EE platform. The eStore application is composed of EJBs and JSP/servlets; together they collaborate to provide the overall functionality of the application. The application also utilizes an eStore database to store data related to a product catalog; shopping carts functions, customer registration and profiles, transaction status and records, and order status.
A customer, using a web browser, initiates an e-commerce transaction with the eStore application. The e-commerce transaction consists of a series of customer actions. A customer typically browses the online catalog, selects products for purchase, associates the selected products with a shopping cart function, enters a user name and password to initiate a secure transaction, supplies order-related information, and places an order.
To support this e-commerce scenario, the system administrator of the merchant's portal configures a unique security domain (with specific security technology and security policies) for the eStore application. A firewall protects this security domain from unauthorized Internet access. The security domain configuration for the eStore application includes secure web access to the eStore application. Secure web access is set up based on the requirements specified in the J2EE specification.
The system administrator sets up a database to manage persistent data for the eStore application. In terms of security, the database system is configured with an independent security domain. This domain has its own set of user accounts, plus its own security policies and mechanisms for authentication and authorization. The system administrator creates a unique database account (EStoreUser) to handle database transactions. The database transactions correspond to different customer driven interactions with the eStore application. The administrator also sets up an additional database account (EStoreAdministrator) to manage the database on behalf of the eStore administrator. This administrative account has a higher level of access privileges. To facilitate better scaling of the eStore application, the system administrator can choose to set the load balancing of database operations across multiple databases. He can also partition persistent data and transactions across multiple database accounts, based on various performance optimization criteria.
Deployment
During the deployment of the eStore application, the deployer sets up access control for all authenticated customer accounts—the customer accounts that are driving e-commerce transactions over the web based on a single role eStoreUserRole. The deployer configures the resource adapter with the security information that is required for the creation of database connections.
This security information is the database account StoreUser and its password. The deployer sets up the principal mapping for accessing the database system. The deployment configuration ensures that all database access is always performed under the security context of the database account EStoreUser. This database account is called Resource Principal. All authenticated customers (referred to as Initiating Principal) map to a single EstoreUser database account. The eStore application uses an implementationspecific mechanism to tie database transactions (performed under a single database account) to the unique identity (social security number or eStore account ID) of the initiating principal. To ensure that database access has been properly authorized, the eStore application also performs access control based on the role of the initiating principal. Because all initiating principals map to a single role, this is in effect a simple case. This scenario describes an n to 1 mapping, where n can be any number. However, depending on the requirements of an application, the deployer can set the principal mapping to be different from an n to 1 mapping. For example, the deployer can map each role to a single resource principal, where a role corresponds to an initiating principal. This results in a mapping of [m principals and n roles] to [n resource principals] where m>=n. When doing such principal mapping, the deployer has to ensure not to compromise the access rights of the mapped principals.
FIG. 1B shows an employee self service application. Company B has developed and deployed an employee self service (ESS) application based on the J2EE platform. This application supports a web interface to the existing Human Resources (HR) applications, which are supported by the ERP system from Vendor X. The ESS application also provides additional business processes customized to the needs of Company B. The application tier is composed of EJBs and JSPs that provide the customization of the business processes and support a company standardized web interface.
The ESS application enables an employee (under the roles of Manager, HR manager, and Employee) to perform various HR functions, including personal information management, payroll management, compensation management, benefits administration, travel management, and HR cost planning.
The information services (IS) department of Company B has deployed its HR ESS application and ERP system in a secure environment on a single physical location. Employees of the organization are permitted access to the HR application. Access is based on the employee's roles and access privileges. In addition, access to the application can only be from within the organization's intranet.
To support the various interaction scenarios related to the ESS application, the system administrator sets up an end to end Kerberos based security domain for this application environment. The system administrator configures the security environment to support single sign-on; the user logs on only once and can then access all the services provided by the ESS application and its underlying ERP system. Single sign on is achieved through the security mechanism and policies specific to the underlying security technology, which in this case is Kerberos. The ERP system administrator configures all legal employees as valid user accounts in the ERP system.
The administrator sets up various roles (Manager, HRManager, and Employee), default passwords, and access privileges. This security information is kept synchronized with the enterprise wide directory service, which is used by Kerberos to perform the initial authentication of endusers.
During deployment of the ESS application, the deployer sets a default delegation policy of client impersonation for EIS sign-on. In this case, the application server and ERP system know that it is the initiating principal accessing their respective services and they perform access control based on this knowledge. In this scenario, both the initiating principal and the resource principal refer to the same principal. This common principal is authenticated using Kerberos and its Kerberos credentials are valid in the security domains of both the application and the ERP system. The deployer sets up access control for all authenticated employees (initiating principal) based on the configured roles—Manager, HR Manager, and Employee. If the ERP system does not support Kerberos, then an alternate scenario is utilized. The deployer or application server administrator sets up an automatic mapping of Kerberos credentials (for the initiating principal) to valid credentials (for the same principal) in the security domain of the ERP system. Note that when the ERP system does support Kerberos, the application server performs no credentials mapping.
An employee initiates an initial login to his client desktop. He enters his user name and password. As part of this initial login, the employee gets authenticated with Kerberos KDC. After a successful login, the employee starts using his desktop environment. He directs his web browser to the URL for the ESS application deployed on the application server. At this point, the initiating principal C authenticates itself to the application server and establishes a session key with the application server. The ESS application is set up to impersonate initiating principal C when accessing the ERP system, which is running on another server.
Though the application server directly connects to the ERP system, access to the ERP system is requested on behalf of the initiating principal. For this to work, principal C needs to delegate its identity and Kerberos credential to the application server and allow the application server to make requests to the ERP system on C's behalf.
In FIG. 1C, Company C has an integrated purchasing application that enables an employee to use a web-based interface to perform multiple purchasing transactions. An employee can manage the entire procurement process, from creating a purchase requisition through invoice approval. The purchasing application also integrates with the enterprise's existing financial applications so that the accounting and financial aspects of the procurement business processes can be tracked.
Applications such as in FIG. 1C were developed and deployed based on the J2EE platform and are composed of EJBs and JSPs. The EJB components provide the integration across the different applications—the logistics application from a separate vendor (this application provides integrated purchasing and inventory management functions) and the financial accounting applications (the applications supported by the legacy system from vendor Y).
Company C is typically a large, decentralized enterprise with geographically distributed business units and departments. In this scenario, different IS departments manage ERP system X and legacy system Y. In addition, ERP system X and legacy system Y can be deployed at secured data centers in different geographic locations. Lastly, the integrated purchasing application has been deployed at a geographic location different from both ERP system X and legacy system Y.
ERP system X and legacy system Y can also be in different security domains, use different security technologies and have their own specific security policies and mechanisms. The integrated purchasing application is deployed in a security domain that is different from both that of ERP system X and legacy system Y. To support the various interaction scenarios for this integrated purchasing application, the ERP system administrator creates a unique account LogisticsAppUser in the ERP system, utilizing a password and specific access rights for this account. This user account is allowed access only to the logistics business processes that are used by the integrated purchasing application. Likewise, the system administrator for the legacy system creates a unique account FinancialAppUser. He also sets up the password and specific access rights for this account. The application server administrator, as part of the operational environment of the application server, configures the access to an organization wide directory. This directory contains security information (name, password, role, and access rights) for all the employees in the organization. It is used for authentication and authorization of employees accessing the purchasing application. Due to their physical separation in this scenario, EISs X and Y are accessed over either a secure private network or over the Internet. This requires that a secure association be established between the application server domain and the EISs. The application server establishes the secure association for a principal by initially authenticating the principal to the target EIS domain. It then propagates the resulting credentials of the authenticated principal to the EIS, and establishes a shared security context, such that data integrity and confidentiality mechanisms can protect the data integrity of messages between the application server and the EIS.
As illustrated and explained above, there are numerous details involved in security management for a wide spectrum of application scenarios. Currently, there is no standard available to multiple applications. This makes security management a labor intensive aspect of application development, with many nearly similar details being customized for individual applications. For developers working on numerous applications, the lack of security standards results in duplicated effort and inefficient expenditure of resources.